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Description 
Technical Field 

[0001] This invention relates to distributed computer services : particularly computer services having online forums. 
Background Information 

[0002] An online forum is a communications interchange in which people may communicate with others through 
successive electronic transmissions between respective computer systems. An online forum, or any other type of 
distributed computer services : may be implemented on a distributed computer system such as that shown in FIG. 1. 
Forum participants (equivalent^, users of the computer services) typically are scattered across a large geographical 
area and communicate with one or more central server systems 100 through respective client systems 102 (e.g.. a 
personal or laptop computer). In practice, the server system 1 00 typically will not be a single monolithic entity but rather 
will be a network of interconnected server computers, possibly physically dispersed from each other, each dedicated 
to its own set of duties and/or to a particular geographical region. In such a case, the individual servers are intercon- 
nected by a network of communication links, in known fashion. One such server system is "America Online" from 
America Online Incorporated of Virginia. 

[0003] Each client system 102 runs client software that allows it to communicate in a meaningful manner with cor- 
responding software running on the server system 100. 

[0004] The client systems 1 02 communicate with the server system 1 00 through various channels, such as a modem 
1 04 connected to a telephone line 1 06 or a direct Internet connection using a transfer protocol such as TCP/I P (Transfer 
Control Protocol/Internet Protocol). The server system 1 00 is responsible for receiving input from the client systems 
102, manipulating the collective body of input information (and possibly information from other sources) into a useful 
format, and retransmitting the formatted information back to one or more clients 102 for output on an output device, 
such as a display screen. 

[0005] Referring to FIG. 2, one type of forum is a "chat room" 200, in which the various.participants 204 {e.g., 
"Allens9," "JOSHUAALEX," etc.) may enter text which appears in a scrolling text window 202 on each participant's 
computer display screen. In the example in FIG. 2, the chat room 200 has 22 participants whose identities (or "screen 
names") are listed in a scrolling window 21 0. A participant 204 may respond to the comment of another participant 204 
by entering a line of text in an edit box 206 and activating {e.g., by clicking with a pointer device, such as a mouse) a 
SEND button 208. In response, the text in the scrolling text window 202 scrolls upwards and the newly entered line of 
text is displayed at the bottom of the scrolling text window 202. In the illustrated example, the last participant to enter 
a comment was JOSHUAALEX, who typed 'TEXAS." 

[0006] The chat room 200 shown in FIG. 2 is "public", meaning that it has multiple participants who were placed in 
the chat room by the computer-service provider and who most likely never have met or conversed with one another 
before. A comment by a participant in a public forum may be seen by all of the participants of the chat room. If a 
participant desires some privacy that participant may "open" and enter a "private" chat room (for example, by clicking 
on a SETUP button 212), and thereafter invite one or more other participants to enter the private chat room. Once in 
a private forum, participants may communicate with one another without fear that uninvited participants will be able to 
see their comments. 

[0007] When a participant in a forum, whether public or private, makes a comment that others in the forum regard 
as offensive, in poor taste, wildly incorrect, or otherwise objectionable, the offending participant most likely will be 
"flamed" by one or more of the other participants. A "flame" is a reprimand or other stringent response directed at the 
offending party. One purpose behind flaming another participant is to dissuade the offender, through embarrassment 
or intimidation, from making further objectionable comments. In this manner, if the offending user chooses to curb his 
or her behavior in response to the flaming, a forum may be crudely regulated or "policed" by the forum's participants. 
However, the offending participant may continue to behave in an objectionable manner. Further, a participant who 
overly "flames" other participants may also be objectionable. Accordingly, participant policing of forums does not always 
work well. In such cases, offended participants may drop out of "flame-filled" forums, and/or the online service must 
devote resources to actively police problematic participants. 

[0008] Other objectionable behavior includes sending one or more messages to "spoof other users as to the sender's 
identity in order to try to get confidential information {e.g., credit card numbers or passwords) sent in response (some- 
times called "password fishing"). 

[0009] Another problem that can arise in online systems is "resource hogging", where a participant uses features 
such as broadcast or multi-cast messaging to send a large number of messages to other users in a short period of 
time (sometimes called "spamming"). Such resource hogging deprives other users of server resources, and can slow 
an online system response time to undesirable levels. 
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[001 0] Accordingly, the inventor has determined that there is a need for a better way to police recalcitrant participants 
in online forums and to reduce spamming. The present invention provides a method and means for accomplishing this 
goal. 

[0011] The document "Nonviolent crowd control" by J Berkman. Proceedings of the ACM SI GUCCS 1 993 User Serv- 
5 ices Conference XXT, San Diego, pp. 1 73-178 describes mechanisms and actions that can cause users and processes 

on a shared computing resource to dominate CPU use and thereby destroy interactive response time to other users. 

Various remedies are described which must be implemented manually by a system administrator. 

[0012] The document "Policing ourselves: Defining the Boundaries of Appropriate Discussion in Online Forums" by 

J Johnson-Eilola et al, Computers and Composition, Vol. 13, No. 3, 1996 pp. 269-291 provides a discourse on bound- 
10 aries of appropriate discussions in on-line forums on computer systems. 

[0013] US 5,265,221 describes an access control mechanism for allowing and denying authorization to computer 

system objects using a set of verbs, parameters, attributes and functions. 

SUMMARY 

15 

[0014] The invention provides a method and means for regulating a user's access to a computer-based service 
according to the steps of claim 1 . According to one aspect, the invention thereby provides for self-policing and auto- 
matically rate-limiting multiple-user online forums. The preferred embodiment of the invention includes a set of rules 
that permit users to censure other users. A censured user has one or more "privileges" (which may include access to 

20 the online computer system or the effective message rate of a communications connection) taken away or diminished; 
the privilege is gradually restored if the censured user behaves. The censuring participant and other pertinent partic- 
ipants are notified of the effect of the censuring on the censured user. In another aspect of the invention, the online 
computer system automatically tracks the rate at which a user sends certain types of messages, and can message 
rate limit a user who uses too many system resources by sending a large number of messages in rapid succession. 

25 The amount of rate limiting may be a function of the amount of censure that has been applied to the user being limited. 
[001 5] Advantages of this invention may include one or more of the following. The techniques described here enable 
a multiple-user online service (e.g., a chat room or other forum) to be self-policing. Access to the computer service for 
a particular user is automatically regulated by the computer based on input from other users concerning the conduct 
of the user under consideration, or based on the message rate of a user. Users of a computer-based system have the 

30 ability to sanction a misbehaving user and thereby have the offending user's access to the system denied or curtailed. 
Unlike the conventional "flaming" approach to policing, which typically fails because it relies on the misbehaving user 
curbing his or her own behavior or results in retaliatory "flaming", the policing techniques described here are based on 
predetermined rules and operate automatically in response to votes cast by other users of the computer system. The 
offending user has no choice in the matter once he or she chooses to misbehave. Because the operation of these 

35 policing techniques are automatic, the computer-based service provider need not expend personnel time and resources 
to police public forums, direct user communications, and the like. 

[001 6] The details of one or more embodiments of the invention are set forth in the accompanying drawings and the 
description below. Other features, objects, and advantages of the invention will be apparent from the description and 
drawings, and from the claims. 

40 

DESCRIPTION OF DRAWINGS 

[0017] FIG. 1 shows a prior art distributed computer system of the type used for providing online computer services. 
[0018] FIG. 2 is a screen shot showing an example of a prior art online computer forum. 
45 [0019] FIG. 3 is a flowchart of a basic embodiment of the self-policing aspect of the invention. 
[0020] FIG. 4 is a flowchart of a basic embodiment of the rate-limiting aspect of the invention. 
[0021] Like reference numbers and designations in the various drawings indicate like elements. 

DETAILED DESCRIPTION 

50 

[0022] The prospect of millions of concurrent users of an online computer system puts great pressure on the ability 
of the system provider to police abusive participants. Accordingly, the invention provides a self-policing online envi- 
ronment that makes participants responsible for their behavior. That is, other participants can express an opinion about 
that behavior, and have that opinion affect the offending user in a negative way and be "visible" to other participants. 
55 Providing such a self-policing user feedback mechanism lowers the cost of providing online services to users and 
provides a more "user-friendly" environment for participants. 

[0023] In another aspect of the invention, the online computer system automatically tracks the rate at which a user 
sends certain types of messages, and can "rate limit" a user who "hogs" too many system resources by sending a 
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large number of messages (or messages of selected types) in rapid succession. 
Participant Self- Policing 

[0024] FIG. 3 is a flowchart of a basic embodiment of the self-policing aspect of the invention. Initially, user A gen- 
erates an event I, such as a message (STEP 300). Event I is transmitted to some number of other participants, such 
as users B and C in a public forum on an online computer system (STEP 302). However, event I may be a direct 
communication between user A to user B : such as by use of the Instant Message™ feature of the America Online 
computer service. User B may feel that event I is "objectionable" or "evil" (a subjective decision by B), and therefore 
generates a "Vote" against the behavior of user A by sending a special type of response message - an "evil" event E 
(STEP 304). In the preferred embodiment, a user cannot "evil" another participant except in response to a message 
from the participant, or otherwise in cases where the participant's actions affect the user doing the "eviling." In order 
to reduce retaliation, users cannot "evil" other participants directly in response to being "eviled". 
[0025] The online system receives event E and checks a database to see whether user B has the right to "evil" user 
A (STEP 306). For example, this step can limit users who themselves have been restricted from "eviling" other users. 
[0026] If user B does not have the right to "evil" user A, then user B is notified of the effect of user B's action on user 
A's "evil index" - a value of how restricted user A is with respect to use of resources on the online system (STEP 308). 
In this case, user B's action has no effect on user A. 

[0027] If user B does have the right to "evil" user A, then user A's "evil index" is modified by a suitable amount, which 
will affect further actions by user A (STEP 310), as described below. The amount of modification can be based on the 
past behavior of user A, or of users A and B. The amount of modification may also depend on the type of "eviling" 
asserted by user B. For example, user B may wish to assert an "eviling" event E anonymously rather than be identified. 
Anonymous "eviling" may be accorded lesser weight. That is, an anonymous "eviling" response may count as fewer 
evil 'Votes" than it would if the eviling user's identity was revealed. In one embodiment, an "eviling" user may set up 
an automatic "eviling" response to all communications from another specific user. In this case, the effect of the "eviling", 
which is intended to discourage communication from the specific user, is given very low weight (equivalently, counts 
as very few evil "votes") because of its automatic invocation. 

[0028] User A's "evil index" is "broadcast" to other users who "know about" user A (STEP 312). For example, such 
users might be all of the participants in a private chat room, or all visitors to a public chat room. In one embodiment, 
a modified "evil Index" is reported to each user in a current chat room's user list and to each user who has the "eviled" 
users on his or her "buddy list". Thus, an "eviled" user is publicly chastised. 

[0029] Thereafter, user A's "evil index" begins to gradually "decay" backto normal overtime (STEP 314). Such decay 
may be linear, exponential, step-wise, or some other function. Meanwhile, user B is notified of the effect of user B's 
action on user A's "evil index" (STEP 308). In this case, user B's action has had an effect on user A. 
[0030] Some of the steps noted above may be done in different order without substantially changing the effect of the 
process. For example, STEPS 312, and 314, and 308 may be performed in different order. 

[0031] A basic "penalty" for having a non-normal "evil index" is denial of access to a forum or the online service until 
the user's "evil index" has decayed back to normal. In a more refined embodiment, a user's "evil, index" affects a rate 
limit which governs a user's ability to send (and/or receive) messages. This feature allows other participants to "evil" 
a user who "flames" or "spams" them, and thus reduce the rate at which the recalcitrant user can send and/or receive 
messages. A description of rate limiting is set forth below. 

[0032] A server database (which may be centralized or distributed) stores a user's "evil index". A user's "evil index" 
can be maintained in a user-record as a global total, or by forum, or both. The value of each "evil index" can be used 
to control the user's ability to log on to the online computer system or access selected forums, and/or the effective rate 
of message or file transmissions. 

[0033] Other rules may applied in different embodiments. For example, the following rules can be implemented: 

A user must be in a forum (e.g., a chat room, but including direct communication between users, such as the 
Instant Message™ feature of the America Online computer service) for a specified amount of time before being 
allowed to "evil" another user in that forum; this reduces "hit-and-run flaming". The minimum amount of time may 
vary from forum to forum, and from user to user (e.g. , a forum "sysop" may be immune to "eviling"). A user's user- 
record in the server database thus would record a time-of-entry for a forum. For example, a user's time-of-entry 
to a forum would be compared to the current time in STEP 306 of FIG. 3 to determine if the user had the right to 
"evil" another participant. 

A user must be in a forum for a specified amount of time before being allowed to "evil" another user who has been 
in that forum for a longer period of time. For example, a user's time-of-entry to a forum would be compared to the 
time-of-entry of another participant in STEP 306 of FIG. 3 to determine if the user had the right to "evil" that other 
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participant. The specified amount of time may vary from forum to forum, and from user to user. 

A user's eviling response may be accorded increased weight (equivalently, counted as extra "evil" votes) based 
on the "seniority" of the "eviling" user. Each additional u nit of time spent in a forum could enhance a user's "seniority : 

5 " thereby allowing long term user's more "eviling" power than new-comers. That is, being "eviled" by an "old-timer" 

can have a greater than normal affect on modification of a chastised user's "evil index" in STEP 310 of FIG. 3. A 
user's user-record in the server database thus would record a total-time-of-access for each forum, which could be 
a "lifetime" total (such that users who had belonged to the online computer service for longer periods would have 
greater "eviling" power than relatively new subscribers to the service) , a running total for a selected period of time, 

10 or a session total. The time period for accumulating extra votes and the "eviling" value of extra votes may vary 

from forum to forum, and from user to user. 

A user may be limited in the number of "eviling" votes that can be cast in any one online session or time period 
(e.g., a day or week). A user's user-record in the server database thus would record the number of "eviling" votes 
15 cast globally or by forum. For example, a user's number of previous "eviling" votes cast could be examined in 

STEP 306 of FIG. 3 to determine if the user had the right to "evil" another participant. 

The amount of modification of a user's "evil index" in STEP 310 of FIG. 3 after being "eviled" is preferably non- 
linear, so that the first few times a user is "eviled" has little effect (and possibly no effect until some threshold level 

20 of accumulated "eviling" votes from several participants are asserted against the user) on the user's "evil index" 

(everyone makes a few mistakes). However, for subsequent times that a user is "eviled", the user's "evil index" 
preferably is modified to a much greater degree, increasing the penalty for recidivism. The determination of how 
much to modify a user's "evil index" can be based on the user's global "evil index" (i.e., a "rap sheer evaluation) 
or forum "evil index" (i.e., a "fresh start" approach). A user's user-record in the server database would thus record 

25 the number of times the user has been "eviled", either globally or by forum, for example. The recorded number 

might be a "lifetime" total or a running total for a selected period of time. The amount of "evil index" modification 
may also vary from forum to forum, and from user to user. 

As an example, each user may be given an initial "evil index" of 100. A first "offense" may reduce that value to 95; 
30 a second "offense" reduces the value to 85; third and subsequent offenses reduce the current value by 15 units. 

Alternatively, each user is given an initial "evil index" of 0 and "eviling" increases that value. If a range of 100 is 
used, a user's "evil index" may be regarded as a "percentage of evil", up to 1 00% "evil". 

The decay rate for returning a user's modified "evil index" to normal can vary from forum to forum. For example, 
35 the decay in chat rooms (where most flaming occurs) may be less than in other forums. Using the example from 

immediately above : the user's "evil index" may "decay" back to "normal" at the rate of 2 units per hour in a chat 
room, but at the rate of 5 units per hour in other forums. 

A user may query a forum to determine the rate of "eviling" within the forum as a measure of how much members 
40 of the forum "evil" one another. A high rate may indicate that one or more members are misbehaving. The system 

keeps track of all users participating in a forum, so the current "eviling" rate is a time-weighted average of the 
number of "eviling" votes cast by the current participants. In an alternative embodiment, a user may query a forum 
to determine the accumulated value of the "evil index" of all current users. 

This measures how often the users have misbehaved in the past, and can serve as an estimate of the likelihood 
45 that the current users will misbehave in the future. The system keeps track of all users participating in a forum, so 

the total "evil index" is the sum of the pertinent forum "evil index" for each participant. 

In some embodiments, a user who has been "eviled" has a lessened ability to "evil" other users (thus reducing 
retaliation). However, some online systems implement message types, such as broadcast or multi-cast messages 

so or self-repeating messages, that are more frequently used than other message types to flame or spam other 

participants. In some embodiments, it may be desirable to allow all users (even those with a modified "evil index", 
and thus possibly restricted in usage rights) to "evil" the originator of such message types. Such a determination 
would be made in STEP 306 of FIG. 3 by examining the message type of event I sent by the originating user. The 
amount of modification of such an originator's "evil index" can be set to be greater than for flaming to discourage 

55 use of such message types for spamming. 

[0034] When a user's "evil index" is modified, the user is notified that privileges, such as rate of messaging, have 
been limited. In one embodiment, a message is sent from the server that contains the user's current "evil index" to the 
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"eviled" user, and optionally includes the current rate of decay back to normal. Such information allows a wide range 
of feedback to be presented to the user about his or her ability to interact with the online computer system. For example, 
a graphical "power meter or "power bar graph" can be used to indicate the "evil index" of the user. For instance, a 
color-coded bar graph can be divided into (1) a green zone to represent that the user's "evil index" is normal; (2) a 
yellow zone to represent that the user's "evil index" has been modified slightly; (3) a red zone to represent that the 
user's "evil index" has been modified significantly; and (4) a black zone to represent that access or message privileges 
have been suspended for a time. However, other methods of informing a recalcitrant user of his or her "evil index" can 
be used. 

[0035] In one embodiment, a user can "rehabilitate" his or her "evil index" by visiting advertisements displayed on 
the online computer system: "visits" can be determined by requiring the user to "click" on an advertisement. The user 
is rewarded with more "power" by adjusting the value of the user's "evil index" more towards normal. 

Automatic Rate Limiting 

[0036] In one embodiment, both input and output messaging rates of a user are limited based on the behavior of the 
user and/or available system resources. Such rate limiting can stop malicious users and errant client computers from 
consuming more than a fair share of online system resources. However, preferably the rate limiting system is weighted 
to tolerate brief bursts of messaging activity while penalizing unacceptably large rates of messaging. Rate limiting can 
also limit aggregate input to a server to a level at which the system is reasonably loaded under normal conditions. Rate 
limiting can also be combined with "eviling" by automatically adjusting a users rate limit parameters based on their "evil 
index." 

[0037] In one embodiment, input rate limiting - from user to server - is conducted on a per user connection basis, 
and within a user connection on a per-message type bases (that is, rate limits for different types of messages may be 
set to different values). In one embodiment rate limiting for a user is achieved in accordance with the following algorithm: 

(1 ) Define A as the running average of inter-message time gaps for the last N messages of selected types that 
the user has attempted to send; a system selected value / is used as the first value for A. Calculation of A can be 
done, for example, on a forum basis (accounting only for messages sent in the current forum), session basis 
(accounting for messages sent in the user's current online session), or message-count basis (accounting for the 
last N messages sent at any time in any forum). 

(2) If A is below a warning threshold W (indicating that the user is approaching a point of sending messages too 
frequently), when the user attempts to send a message, send the user a warning message but transmit the user's 
message. 

(3) If A is below a rate limit threshold Ft (indicating that the user is sending messages too frequently) when the 
user attempts to send a message, send the user a warning message and drop the user's message. 

(4) Repeat the above steps until A rises above a clear threshold C (indicating that the user is not sending messages 
too frequently), at which time the rate limiting condition is considered cleared. 

(5) If at any time A drops below a disconnect threshold D, disconnect the user. 

[0038] FIG. 4 is a flowchart of a basic embodiment of the rate-limiting aspect of the invention, showing a slightly 
different order for the steps described above. A user attempts to send a message (STEP 400). Average A is computed 
(STEP 402). If A is less than a disconnect threshold D (STEP 404), the user is disconnected (STEP 406). Otherwise, 
if A is less than a rate limit threshold R (STEP 408), the message is dropped, the user is warned that the rate limited 
has been exceeded, and the user is flagged as "rate limited" (STEP 410). 

[0039] Otherwise, if A is less than a warning threshold W (STEP 412), a determination is made as to whether the 
user is rate limited (STEP 41 4). If not, the message is sent, but the user is warned that the rate limit is being approached 
(STEP 41 6). Otherwise, the message is dropped and the user is warned that the rate limited has been exceeded (STEP 
418). 

[0040] If A is not less than the warning threshold M/(STEP 412), and A is less than a clear threshold C(STEP 420), 
a determination is made as to whether the user is rate limited (STEP 421). If not, the message is sent (STEP 423)! 
Otherwise, the message is dropped and the user is warned that the rate limited has been exceeded (STEP 418). 
[0041] Finally, if A is not less than the clear threshold C (STEP 420), the rate limit flag for the user is cleared (STEP 
422) and the message is sent (STEP 423). 

[0042] The rate limiting algorithm supports several "tunable" parameters: 

• The running average of inter-message time gaps - A 

• The number of message receptions over which A is calculated - N 

• An initial average - / 
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• A clear threshold - C 

• A warning threshold - W 

• A rate limit threshold - R 

• A disconnect threshold - D 

5 

[0043] In one embodiment, the values for C, W, R, and D are selected such that C > W> R > D. The initial average 
rate / can be weighted to increase the algorithm's tolerance of bursts of activity, such as "chatty startups" when a user 
joins a forum and sends several messages in succession. The threshold rates can be set globally for all user's, or 
"tuned" for each user. 

10 [0044] In one embodiment; the difference between the clear threshold C and the rate limit threshold R can be "tuned" 
by the online computer system to alter the interval between commencement of rate limiting for a user and the resumption 
of normal activity. The difference between C and R may be automatically increased, for example, if the user sends 
excessive "spamming" type messages at too great a rate. Further, the threshold values C, W, R, and Dean be dynam- 
ically modified by the online system as a way of limiting system resource usage if too many users are simultaneously 

15 using the system. 

[0045] As noted above, when a user's message rate is limited, the user is notified. In one embodiment, a message 
is sent from the server to a rate limited user that contains values for each of the parameters outlined above, and another 
message is sent the next time that the server will accept messages from the user without restriction. Such information 
allows a wide range of feedback to be presented to the user about his or her ability to interact with the online computer 

20 system. For example, a graphical "power meter" or "power bar graph" can be used to indicate the "health" or "power" 
of the user. For instance, a color-coded bar graph can be divided into (1 ) a green zone to represent that no rate limiting 
is in effect; (2) a yellow zone to represent that the user's, message rate is near the point where rate limiting would take 
effect; (3) a red zone to represent that message rate limiting is in effect; and (4) a black zone to represent that access 
privileges. have been suspended for a time. However, other methods can be used to inform a recalcitrant user of his 

25 or her message rate limit status. 

[0046] In one embodiment, a user can "rehabilitate" his or her message rate limit status by visiting advertisements 
displayed on the online computer system. The user is rewarded with more "power" by adjusting the parameters. 
[0047] In one embodiment, output rate limiting - from server to user - is performed in a similar manner, with the 
following differences: 

30 

6) The system server audits the rate of outgoing error messages of selected types (e.g., RATE__TO_HOST), and 
uses the above rate limiting algorithm with R=D f to prevent excessive load due to handling users that are generating 
rate errors. 

7) The system server can limit the rate of outgoing messages of selected types [e.g., those types that may be used 
35 for spamming) using the above rate limiting algorithm when A < R. In this case, a notice message can be sent to 

the user, to the user's intended recipient, and to a server storing the user's "evil index". The intended recipient can 
"evil" the sending user, or the system server can automatically modify the user's "evil index" based on the sending 
of excessive "spamming" type messages at too great a rate. 

40 [0048] The algorithms described above prevent abuse of online system resources without causing undue "pain" to 
users, including "power users" and users who are subject to delays and input/output timing changes by non-ideal 
networks (which can cause otherwise normal user activity to appear to be unacceptable activity). 

Rate Limiting and "Eviling" 

45 

[0049] The concepts of automatic rate limiting and modification of a user's "evil index" can be combined to provide 
a refined self-policing, automatic rate limiting system that can regulate an "eviled" user's ability to participate in forums 
without requiring total exclusion from the forum. Further, a user's current global or forum "evil index" can be used to 
modify the parameters used to effect automatic {i.e., "non- eviled" basis) rate limiting for the user. For example, a user's 

so ability to interact in a forum can be rate limited by modifying the values for A, C, W t R, and/or D as a function of whether 
the user's "evil index" has been modified, or as a function of the current value of the user's "evil index". 
Conversely, the amount of modification of a user's "evil index" can be a function of the current value of A. Thus, con- 
ceptually, a user's permitted message rate R p is a function of the user's "evil index" E/plus the user's rate of attempted 
message activity A. R p = f(EI) + g(A) 

55 [0050] Conceptually, each user's user-record thus may look like the following table: 
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# times 
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time-of- 
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total- 
time of- 
access 
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Global 
value 
























Forum 1 
value 
























Forum 2 
value 
























etc. 

























[0051] Separate "lifetime" and "session" records may be kept where useful. Of course, other or different information 
may be recorded for each user, and other ways of organizing such data may be used. Further, users may be assigned 
a "class" designation (such as "sysop" (system operator), corporate users, paying members, non-paying members, 
etc.) which can be given weight in making a determination of right to "evil" or absolute or relative immunity from being 
"eviled" in STEP 306 of FIG. 3. 

[0052] In setting rate parameter values for a user, a global rate table can be used which is indexed by a user's "evil 
index"; that is, message rate parameters are a function of the user's global or forum "evil index". A conceptual example 
of one such table might be the following (AA represents an optional adjustment to be applied to the calculated value 
of A) : 



"evil index" value 


AA 


C 


W 


R 


D 


0-20 












21-40 












41-60 












61-80 












81-90 












91-95 












96-100 













[0053] The values for A, C, W, R, and D in this table can be defined globally or by forum. If by forum, the values can 
be defined in absolute terms or as relative offsets to a global table. Multiple tables of this form also can be defined, 
indexed by message type, so that misuse of certain types of messages are punished more than misuse of other mes- 
sage types. 

[0054] Alternatively, a non-tabular implementation could be used instead of the global rate table described above. 
For example, a user's rate parameter values (AA, C, W, R, D) could be defined as a function describing a relation 
between these quantities. 

implementation 

[0055] The methods and mechanisms described here are not limited to any particular hardware or software config- 
uration, but rather they may find applicability in any computing or processing environment used in connection with 
online computer services. 

[0056] The invention may be implemented in hardware or software, or a combination of both. However, preferably, 
the invention is implemented in computer programs executing on programmable computers each comprising at least 
one processor, at least one data storage system (including volatile and non-volatile memory and/or storage elements), 
at least one input device, and at least one output device. Program code is applied to input data to perform the functions 
described herein and generate output information. The output information is applied to one or more output devices, in 
known fashion. 

[0057] Each program is preferably implemented in a high level procedural or object oriented programming language 
to communicate with a computer system. However, the programs can be implemented in assembly or machine lan- 
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guage, if desired. In any case, the language may be a compiled or interpreted language. 

[0058] Each such computer program is preferably stored on a storage media or device {e.g., ROM or magnetic 
diskette) readable by a general or special purpose programmable computer, for configuring and operating the computer 
when the storage media or device is read by the computer to perform the procedures described herein. The inventive 
5 system may also be considered to be implemented as a computer-readable storage medium, configures with a com- 
puter program, where the storage medium so configured causes a computer to operate in a specific and predefined 
manner to perform the functions described herein. 

[0059] A number of embodiments of the present invention have been described. Nevertheless, it will be understood 
that various modifications may be made without departing from the scope of the invention as defined with reference 
10 to the following claims. 

Claims 

15 1 . A method, performed on a computer system (1 00), of regulating a user's (1 02) access to a computer-based service, 
the method comprising the steps of: 

(a) receiving (304) input about a first user from at least one other user of the computer-based service; 

(b) evaluating (306) the received input; and 

20 (c) modifying (310) the first user's ability to access the computer-based service based on a result of such 

evaluating. 

2. The method of claim 1 , in which the step of receiving input comprises gathering a vote from at least one other user 
of the computer-based service, the vote being cast in response to action taken by the first user 

25 

3. The method of claim 2 : in which the step of evaluating (306) comprises applying predetermined access limiting 
criteria to the cast vote. 

4. The method of claim 2, in which the step of evaluating (306) further includes determining whether each other user 
30 is permitted to cast a vote against the first user. 

5. The method of claim 4, in which the step of determining further includes evaluating whether a voting user has been 
accessing at least a portion of the computer-based service for a minimum amount of time. 

35 6. The method of claim 4, in which the step of determining further includes evaluating whether a voting user has been 
accessing at least a portion of the computer-based service for a longer amount of time than the first user. 

7. The method of claim 4, in which the step of determining further includes limiting the number of votes a user may cast. 

40 8. The method of claim 2, in which the step of evaluating (306) further includes giving extra weight to votes cast by 
another user against the first user if the other user has been accessing at least a portion of the computer-based 
service for a selected amount of time. 

9. The method of claim 2, in which the step of modifying (310) comprises denying the first user full access to the 
45 computer-based service based on the result of the evaluating. 

10. The method of claim 9, further comprising the step of allowing (314) the first user to regain full access to the 
computer-based service based on predetermined access resumption criteria. 

50 11. The method of claim 1 , further comprising the step of notifying (31 2) selected other users that the first user's ability 
to access the computer-based service has been modified. 

12. The method of claim 1 : further comprising the step of providing an indicator of an amount of modification by ail 
users accessing at least a portion of the computer-based service. 



55 



13. The method of claim 1 , in which the computer-based service comprises an online public forum. 

14. The method of claim 1 , further comprising the step of permitting the first user to vote against another user based 
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on a message type sent by such other user after the first user's ability to access the computer-based service has 
been modified. 

15. The method of claim 1 further comprising the steps of: 

(a) computing (402) an average message rate for messages originated by the first user's connection to the 
computer-based service; 

(b) comparing (404,408,412,420) the first user's average message rate to a rate limit threshold (D,R,W,C); 

(c) if the average message rate exceeds the rate limit threshold, then modifying (406,410,416,418) the first 
user's ability to access the computer-based service. 

16. The method of claim 15, further comprising the steps of: 

(a) comparing (404) the user's average message rate to a disconnect threshold (D); ; 

(b) if the average message rate exceeds the disconnect threshold, then denying (406) the user access to the 
computer-based service. 

17. The method of claim 15, further comprising the step of allowing (422) the user full access to the computer-based 
service if the average message rate falls below a clear threshold (C). 

18. The method of claim 17, further comprising the step of adjusting any of the average message rate, the rate limit 
threshold, the disconnect threshold, or the clear threshold in response to negative Input about the user from at 
least one other user of the computer-based service. 

19. The method of claim 17, wherein the step of computing (402) an average message rate for messages originated 
by the user's connection includes counting only messages of selected types. 

20. The method of claim 17, wherein the step of computing (402) an average message rate for messages includes 
starting with an initial average message rate. 

21. The method of claim 20, further comprising adjusting a value of the initial average message rate to vary the com- 
puter-based service's tolerance of initial messaging activity. 

22. The method of claim 1 further comprising adjusting an index representative of the first user's activities based on 
the received input, and carrying out said modifying step based on said first user's index. 

23. The method of claim 22, further comprising the step of limiting received input only to other users who have been 
affected by the first user's activities. 

24. The method of claim 22, in which the index representative of the first user's activities corresponds to the appro- 
priateness of the first user's behavior in using the computer-based service. 

25. The method of claim 22, in which the input received from the at least one other user is sent anonymously. 

26. The method of claim 25 : in which adjustment of the first user's index comprises according reduced significance to 
anonymous input received from the at least one other user. 

27. The method of claim 22 in which the input received from the at least one other user is sent automatically in response 
to action taken by the first user. 

28. The method of claim 27, in which adjustment of the first user's index comprises according reduced significance to 
automatic input received from the at least one other user. 

29. The method of claim 22, in which adjustment of the first user's index comprises according varied significance to 
received input based on a class to which the at least one other user belongs. 

30. The method of claim 29, in which adjustment of the first user's index comprises according increased significance 
to input received from a user belonging to a system operator class. 
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31 . The method of claim 29 : in which adjustment of the first user's index comprises according reduced significance to 
input received from a user belonging to a non-paying member class. 

32. The method of claim 29, in which adjustment of the first user's index comprises according varied significance to 
5 received input based on a seniority level of the at least one other user. 

33. A computer program, residing on a computer-readable medium, for regulating a first user's access to a computer- 
' based service, comprising instructions for causing a computer to carry out the steps of any one of claims 1 to 32. 



15 



Patentanspruche 

1. Auf einem Computersystem (100) ausgefiihrtes Verfahren zum Regeln des Zugangs eines Benutzers (102) zu 
einem Computer-basierten Dienst, wobei das Verfahren folgende Schritte umfaBt: 



(a) Empfangen (304) einer Eingabe uber einen ersten Benutzervon mindestens einem anderen Benutzer des 
Computer-basierten Dienstes, 

(b) Auswerten bzw. Bewerten (306) der empfangenen Eingabe, und 

(c) Modifizieren (310) der Moglichkeit des Zugangs des ersten Benutzers zu dem computer-basierten Dienst, 
20 basierend auf einem Ergebnis einer solchen Auswertung bzw. Bewertung. 

2. Verfahren nach Anspruch 1 , bei dem der Schritt des Empfangens der Eingabe ein Sammeln einer Stimmabgabe 
von mindestens einem anderen Benutzer des computer-basierten Dienstes umfasst, wobei die Stimme in Reaktion 
auf eine durch den ersten Benutzer unternommene Aktion bzw. Handlung abgegeben wird. 

25 

3. Verfahren nach Anspruch 2, bei dem der Schritt des Auswertens bzw. Bewertens (306) das Anwenden vorbe- 
stimmter Zugangs-Beschrankungskriterien auf die abgegebene Stimme umfasst. 

4. Verfahren nach Anspruch 2 : bei dem der Schritt des Auswertens bzw. Bewertens (306) ferner die Bestimmung 
30 umfasst, ob es jedem anderen Benutzer erlaubt ist, eine Stimme gegen den ersten Benutzer abzugeben. 

5. Verfahren gemaf3 Anspruch 4, bei dem der Schritt des Bestimmens ferner das Auswerten bzw. Bewerten umfasst, 
ob ein. stimmabgebender Benutzer mindestens auf einen Teil des computer-basierten Dienstes uber eine minimale 
Zeitspanne hinweg Zugang bzw. Zugriff hatte. 

35 

6. Verfahren gemaG Anspruch 4, bei dem der Schritt des Bestimmens ferner das Auswerten bzw. Bewerten umfasst, 
ob ein stimmabgebender Benutzer auf mindestens einen Teil des computer-basierten Dienstes uber eine langere 
Zeitspanne als der erste Benutzer Zugang hatte. 

40 7. Verfahren nach Anspruch 4, bei dem der Schritt des Bestimmens ferner das Begrenzen der Anzahl von Stimmen 
umfasst, die ein Benutzer abgeben kann. 

8. Verfahren nach Anspruch 2, bei dem der Schritt des Auswertens bzw. Bewertens (306) ferner umfasst, dass durch 
einen anderen Benutzer gegen den ersten Benutzer abgegebenen Stimmen zusatzliches Gewicht zugeteilt wird, 

45 falls der andere Benutzer auf mindestens einen Tei! des computer-basierten Dienstes uber eine ausgewahlte Zeit- 

spanne Zugang hatte. 

9. Verfahren nach Anspruch 2, bei dem der Schritt des Modifizierens (310) umfasst, dass dem ersten Benutzer auf 
der Basis des Ergebnisses der Auswertung bzw. Bewertung ein voller Zugang zu dem computer-basierten Dienst 

so verweigert wird. 



10. Verfahren nach Anspruch 9, ferner mit dem Schritt, dem ersten Benutzer auf der Basis von vorbestimmten Zu- 
gangs-Wiederaufnahmekriterien zu gestatten (314), den vollen Zugang zu dem computer-basierten Dienst zuruck- 
zuerlangen. 

55 

11. Verfahren nach Anspruch 1 , ferner mit dem Schritt des Benachrichtigens (312) von ausgewahtten anderen Benut- 
zern, dass die Moglichkeit des ersten Benutzers zum Zugang zu dem computer-basierten Dienst modifiziert worden 
ist. 
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12. Verfahren nach Anspruch 1 , ferner mit dem Schritt des Vorsehens eines Anzeigers eines Modifzierungsumfangs 
durch alle Benutzer, die mindestens auf einen Teil des computer-basierten Dienstes zugreifen. 

13. Verfahren nach Anspruch 1, wobei der computer-basierte Dienst ein offentliches Online-Forum umfasst. 

14. Verfahren nach Anspruch 1, ferner mit dem Schritt, es dem ersten Benutzer zu gestatten, gegen einen anderen 
Benutzer auf der Basis eines durch einen soichen anderen Benutzer gesendeten Nachrichtentyps zu stimmen, 
nachdem die Moglichkeit des ersten Benutzers zum Zugang zu dem computer-basierten Dienst modifiziert worden 
ist. 

15. Verfahren nach Anspruch 1 , ferner mit folgenden Schritten: 

(a) Berechnen (402) einer durchschnittlichen Nachrichtenrate bzw. -menge fur Nachrichten, die von der Ver- 
bindung des ersten Benutzers zu dem computer-basierten Dienst stammen, 

(b) Vergleichen (404,408,412,420) der durchschnittlichen Nachrichtenmenge des ersten Benutzers mit einem 
Mengen-Grenzschwellenwert (D,R,W,C), 

(c) falls die durchschnittliche Nachrichtenmenge den Mengen-Grenzschwellenwert Qbersteigt, Modifizieren 
(406,410,416,418) der Zugangsmoglichkeit des ersten Benutzers zu dem computer-basierten Dienst. 

16. Verfahren nach Anspruch 15, ferner mit den folgenden Schritten: 

(a) Vergleichen (404) der durchschnittlichen Nachrichtenmenge des Benutzers mit einer Verbindungstren- 
nungsschwellenwert (D), 

(b) falls die durchschnittliche Nachrichtenmenge den Verbindungstrennungsschwellenwert ubersteigt, dem 
Benutzer Verweigern (406) des Zugangs zu dem computer-basierten Dienst. 

17. Verfahren nach Anspruch 15, ferner mit dem Schritt des dem Benutzer Gestattens (422) des voilen Zugangs zu 
dem computer-basierten Dienst, falls die durchschnittliche Nachrichtenmenge unter einen Losch- bzw. Ruckstell- 
schwellenwert (C) fallt. 

18. Verfahren nach Anspruch 17, ferner mit dem Schritt des Anpassens der durchschnittlichen Nachrichtenmenge, 
des Mengen-Grenzschwellenwerts, des Verbindungstrennungs-Schwellenwerts Oder des Ruckstell-Schwellen- 
werts in Reaktion auf eine negative Eingabe iiber den Benutzer von mindestens einem anderen Benutzer des 
computer-basierten Dienstes. 

19. Verfahren nach Anspruch 17, wobei der Schritt des Berechnens (402) einer durchschnittlichen Nachrichtenmenge 
fur von der Verbindung des Benutzers stammende Nachrichten das Zahlen von Nachrichten nur ausgewahlter 
Arten umfasst. 

20. Verfahren nach Anspruch 17, wobei der Schritt des Berechnens (402) einer durchschnittlichen Nachrichtenmenge 
fur Nachrichten das Starten mit einer anfanglichen durchschnittlichen Nachrichtenmenge umfasst. 

21 . Verfahren nach Anspruch 20, das ferner das Einstellen eines Werts der anfanglichen durchschnittlichen Nachrich- 
tenmenge umfasst, urn die Toleranzgrenze des Computer-basierten Dienstes gegeniiber anfanglicher Nachrich- 
tenaktivitat zu variieren. 

22. Verfahren nach Anspruch 1 , das ferner das Einstellen bzw. Anpassen eines Index, der fur die Aktivitaten des ersten 
Benutzers reprasentativ ist, basierend auf der empfangenen Eingabe, und das Ausfuhren des Modifizierungs- 
schritts, basierend auf dem Index des ersten Benutzers, umfasst. 

23. Verfahren nach Anspruch 22, das ferner den Schritt des Begrenzens bzw. Einschrankens der empfangenen Ein- 
gabe nur auf Benutzer umfasst, die durch die Aktivitaten des ersten Benutzers beeinflusst worden sind. 

24. Verfahren nach Anspruch 22, bei dem der fur die Aktivitaten des ersten Benutzers representative Index der An- 
gemessenheit des Verhaltens des ersten Benutzers bei der Benutzung des computer-basierten Dienstes ent- 
spricht. 

25. Verfahren nach Anspruch 22, bei dem die von dem mindestens einen anderen Benutzer empfangene Eingabe 
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anonym gesendet wird. 

26. Verfahren nach Anspruch 25, bei dem die Anpassung des Index des ersten Benutzers das Beimessen einer re- 
duzierten Bedeutung gegenuber der von dem mindestens einen anderen Benutzer empfangenen Eingabe umfasst. 

27. Verfahren nach Anspruch 22, bei dem die von dem mindestens einen anderen Benutzer empfangene Eingabe 
automatisch in Reaktion auf eine durch den ersten Benutzer unternommene Aktion gesendet wird. 

28. Verfahren nach Anspruch 27, bei dem die Anpassung bzw. Einstellung des Index des ersten Benutzers ein Bei- 
messen reduzierter Bedeutung gegenuber einer von dem mindestens einen anderen Benutzer empfangenen au- 
tomatischen Eingabe umfasst. 

29. Verfahren nach Anspruch 22, bei dem die Anpassung des Index des ersten Benutzers ein Beimessen variierender 
Bedeutung gegenuber der empfangenen Eingabe, basierend auf einer Klasse, zu der der mindestens eine andere 
Benutzer gehort, umfasst. 

30. Verfahren nach Anspruch 29, bei dem die Anpassung des Index des ersten Benutzers das Beimessen einer ver- 
starkten Bedeutung gegenuber einer Eingabe, die von einem zu einer System-Operator-Klasse gehorenden Be- 
nutzer empfangen wurde, umfasst. 

31. Verfahren nach Anspruch 29, bei dem die Anpassung des Index des ersten Benutzers das Beimessen einer re- 
duzierten Bedeutung gegenuber einer Eingabe, die von einem zu einer Klasse nicht-zahlender Mitglieder geho- 
renden Benutzer empfangen wurde, umfasst. 

32. Verfahren nach Anspruch 29, bei dem die Anpassung des Index des ersten Benutzers ein Beimessen variierender 
Bedeutung gegenuber einer empfangenen Eingabe, basierend auf einem Senioritatsniveau des mindestens einen 
anderen Benutzers, umfasst. 

33. Auf einem computerlesbaren Medium befindliches Computerprogramm zum Regeln des Zu gangs eines ersten 
Benutzers zu einem computer-basierten Dienst mit Befehlen, die einen Computer veranlassen, die Schritte irgend- 
eines der Anspruche 1 bis 32 auszufuhren. 



Revendications 

1. Procede, execute par un systeme informatique (100), de regulation d'un acces d'un utilisateur (102) a un service 
assiste par ordinateur, le procede comprenant les etapes : 

(a) de reception (304) d'une entree concemant un premier utilisateur d'au moins un autre utilisateur du service 
assiste par ordinateur ; 

(b) devaluation (306) de I'entree recue ; et 

(c) de modification (310) de I'habilite du premier utilisateur a acceder au service assiste par ordinateur sur la 
base d'un resultat de cette evaluation. 

2. Procede selon la revendication 1 , dans lequel I'etape de reception d'une entree comprend la collecte d'un vote 
provenant d'au moins un autre utilisateur du service assiste par ordinateur, le vote etant lance en reponse a une 
action prise par le premier utilisateur. 

3. Procede selon la revendication 2, dans lequel I'etape devaluation (306) comprend ('application de criteres de 
limitation d'acces predetermines au vote lance. 

4. Procede selon la revendication 2, dans lequel I'etape d' evaluation (306) comprend en outre la determination du 
fait que chaque autre utilisateur peut lancer un vote contre le premier utilisateur. 

5. Procede selon la revendication 4, dans lequel I'etape de determination comprend en outre revaluation du fait qu'un 
utilisateur votant a accede au moins a une partie du service assiste par ordinateur pendant une duree minimale. 

6. Procede selon la revendication 4, dans lequel I'etape de determination comprend en outre revaluation du fait qu'un 
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utilisateur votant a accede au moins a une partie du service assiste par ordinateur pendant une duree plus longue 
que le premier utilisateur. 

7. Procede selon la revendication 4, dans lequel I'etape de determination comprend en outre la limitation du nombre 
de votes qu'un utilisateur peut lancer. 

8. Procede selon la revendication 2, dans lequel I'etape devaluation (306) comprend en outre le fait de donner un 
poids supplemental a des votes lances par un autre utilisateur contre le premier utilisateur si I'autre utilisateur 
a accede au moins a une partie du service assiste par ordinateur pendant une duree choisie. 

9. Procede selon la revendication 2, dans lequel I'etape de modification (310) comprend I 'interdiction, pour le premier 
utilisateur, d'un acces total au service assiste par ordinateur sur la base du resultat de revaluation. 

10. Procede selon la revendication 9, comprenant en outre I'etape consistant a autoriser (314), le premier utilisateur, 
a regagner un acces total au service assiste par ordinateur sur la base de criteres de reprise d'acces predetermines. 

11. Procede selon la revendication 1 , comprenant en outre I'etape de notification (312) a d'autres utilisateurs choisis 
du fait que I'habilite du premier utilisateur a acceder au service assiste par ordinateur a ete modifiee. 

12. Procede selon la revendication 1, comprenant en outre I'etape de fourniture d'un indicateur d'une quantrte de 
modifications par tous les utilisateurs accedant au moins a une partie du service assiste par ordinateur 

13. Procede selon la revendication 1 , dans lequel le service assiste par ordinateur comprend une table ronde publique 
en ligne. 

14. Procede selon la revendication 1, comprenant en outre I'etape consistant a permettre, au premier utilisateur, de 
voter contre un autre utilisateur sur la base d'un type de message envoye par cet autre utilisateur, apres modifi- 
cation de I'habilite du premier utilisateur a acceder au service assiste par ordinateur. 

15. Procede selon la revendication 1, comprenant en outre les etapes : 

(a) de calcul (402) d'un taux moyen de messages pour des messages ayant pour origine la premiereconnexion 
de I'utilisateur au service assiste par ordinateur ; 

(b) de comparaison (404, 408, 412, 420) du taux moyen de messages du premier utilisateur avec un seuil 
limite de taux (D, R, W, C) ; 

(c) si le taux moyen de messages depasse le seuil limite de taux, de modification par la suite (406, 410, 416, 
41 8) de I'habilite du premier utilisateur a acceder au service assiste par ordinateur. 

16. Procede selon la revendication 15, comprenant en outre les etapes : 

(a) de comparaison (404) du taux moyen de messages de I'utilisateur avec un seuil de deconnexion (D) ; 

(b) si le taux moyen de messages depasse le seuil de deconnexion, d' interdiction par la suite (406) pour 
I'utilisateur d'acceder au service assiste par ordinateur. 

17. Procede selon la revendication 15, comprenant en outre I'etape consistant a autoriser (422), a I'utilisateur, un 
acces total au service assiste par ordinateur si le taux moyen de messages tombe en-deca d'un seuil de suppres- 
sion (C). KK 

18. Procede selon la revendication 17, comprenant en outre I'etape de reglage de I'un quelconque du taux moyen de 
messages, du seuil limite de taux, du seuil de deconnexion, ou du seuil de suppression, en reponse a une entree 
negative concernant I'utilisateur provenant d'au moins un autre utilisateur du service assiste par ordinateur. 

19. Procede selon la revendication 17, dans lequel I'etape de calcul (402) d'un taux moyen de messages pour des 
messages ayant pour origine la connexion de I'utilisateur comprend le comptage uniquement de messages de 
types choisis. 

20. Procede selon la revendication 1 7, dans lequel I'etape de calcul (402) d'un taux moyen de messages de messages 
inclut le fait de demarrer avec un taux moyen de messages initial. 
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21. Procede selon la revendication 20, comprenant en outre le reglage d'une valeur du taux moyen de messages 
initial pour faire varier la tolerance d'activite de messagerie initiale du service assiste par ordinateur. 

22. Procede selon la revendication 1 , comprenant en outre le reglage d'un index representatif des activites du premier 
5 utilisateur sur la base de I'entree recue, et I'execution de ladite etape de modification sur la base de I'index du 

premier utilisateur 

23. Procede selon la revendication 22, comprenant en outre l'6tape de limitation de I'entr6e recue seulement pour 
d'autres utilisateurs qui ont ete affectes par les activites du premier utilisateur. 

10 

24. Procede selon la revendication 22, dans lequel I'index representatif des activites du premier utilisateur correspond 
au cote approprie du comportement du premier utilisateur lors de Putilisation du service assiste par ordinateur. 

25. Procede selon la revendication 22, dans lequel I'entree recue du au moins un autre utilisateur est envoyee de 
15 maniere anonyme. 

26. Procede selon la revendication 25, dans lequel le reglage de I'index du premier utilisateur comprend une signifi- 
cation reduite en concordance avec une entree anonyme recue d'au moins un autre utilisateur. 

20 27. Procede selon la revendication 22, dans lequel I'entree recue d'au moins un autre utilisateur est envoyee auto- 
matiquement en reponse a une action prise par le premier utilisateur. 

28. Procede selon la revendication 27, dans lequel te reglage de I'index du premier utilisateur comprend une signifi- 
cation reduite en concordance avec une entree automatique recue d'au moins un autre utilisateur. 

25 

29. Procede selon la revendication 22, dans lequel le reglage de I'index du premier utilisateur comprend une signifi- 
cation qui varie en concordance avec une entr6e recue sur la base d'une classe a laquelle appartient ledit au 
moins un autre utilisateur. 

30 30. Procede selon la revendication 29, dans lequel le reglage de I'index du premier utilisateur comprend une signifi- 
cation accrue en concordance avec une entree recue d'un utilisateur appartenant a une classe d'operateurs de 
systeme. 

31. Procede selon la revendication 29, dans lequel le reglage de I'index du premier utilisateur comprend une signifi- 
es cation r6duite en concordance avec une entree recue d'un utilisateur appartenant a une classe d'abonnes non 

payants. 

32. Procede selon la revendication 29, dans lequel le reglage de I'index du premier utilisateur comprend une signifi- 
cation qui varie en concordance avec une entree recue sur la base d'un niveau d'anciennete dudit au moins un 

40 autre utilisateur. 

33. Programme informatique, se trouvant sur un support pouvant etre lu par ordinateur, pour reguler un acces du 
premier utilisateur a un service assiste par ordinateur, comprenant des instructions amenant un ordinateur a exe- 
cuter les stapes selon Tune quelconque des revendications 1 a 32. 

45 



50 
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